Эта статья — первая часть серии материалов, посвященных эволюции сетевых стеков, лежащих в основе Hetzner Cloud, и их архитектуры. В этой статье мы рассмотрим проделанную нами разработку и то, как работает текущий сетевой стек на основе Open vSwitch. Хотя сетевой стек для облачных серверов и балансировщиков нагрузки схож, мы сосредоточимся на облачных серверах и хостах виртуализации (хостах виртуальных машин), поскольку они предоставляют больше сервисов и функций.

Для краткости мы исключим из рассмотрения плоскость управления облаком, которая управляет всеми серверами, балансировщиками нагрузки, частными сетями и т.д., и рассмотрим только сетевой стек на хостах.

Как мы работаем
Для работы всех облачных продуктов необходимы универсальные и надежные варианты подключения, чтобы наши клиенты и, возможно, их клиенты могли получать доступ к сервисам, работающим в нашей сети.

В компании Hetzner мы в целом верим в решения, которыми владеем и можем управлять самостоятельно, а также в наличие базовых элементов, на основе которых можно строить дальнейшие проекты. Сеть, и особенно сетевое подключение для наших облачных сервисов, не является исключением.

Хотя технологии за эти годы изменились, мы всегда отдавали предпочтение решениям, где движущиеся части находятся на хостах, а не сложной и замысловатой физической сетевой инфраструктуре. В результате мы разработали систему таким образом, чтобы физическая сеть обеспечивала стабильное IP-соединение с хостами, а хосты предоставляли сетевые функции более высокого уровня. К ним относятся межсетевые экраны, частные сети и вспомогательные инфраструктурные сервисы.

Запуская эти сервисы и сетевые функции на хостах, мы получаем большую свободу и гибкость при проектировании и создании нашего продукта, и не ограничиваемся тем, что предлагают поставщики оборудования. Таким образом, мы обеспечиваем четкое разделение задач между командами и технологиями и можем ограничить зону поражения одним хостом в случае (большинства) ошибок. Это также означает, что мы можем и должны полностью владеть решением и адаптировать его к нашим потребностям, но это и так заложено в нашей ДНК.

Немного истории
Исторически сложилось так, что компания Hetzner использовала различные технологии для обеспечения связи для своих облачных продуктов.

На начальном этапе, в 2011 году, виртуальные серверы Hetzner vServers использовали жесткие диски, нативные мосты Linux и статические маршруты. Они обеспечивали двухстековое подключение со скоростью до 1 Гбит/с на хост. В итоге, с такой конфигурацией работало около 25 000 экземпляров.

Следующая версия продукта была запущена в сентябре 2015 года с гиперконвергентной конфигурацией на базе Ceph. Она перешла на динамическую маршрутизацию через BGP и конфигурацию моста Linux с использованием NAT 1:1 для IPv4 и полностью маршрутизируемых префиксов IPv6. Это обеспечило лучшую мобильность IP-адресов и обслуживание хостов без влияния на клиентов. В 2016 году каналы связи с хостами были модернизированы до 2 x 10 Гбит/с. Эта конфигурация просуществовала до 2018 года и разрослась примерно до 50 000 экземпляров.

Когда Hetzner Cloud был запущен в 2018 году, мы отказались от NAT и перешли на прямую маршрутизацию IPv4. В июле 2019 года мы представили плоскость данных на основе Open vSwitch и добавили поддержку частных облачных сетей на основе инкапсуляции VXLAN. В ноябре 2020 года мы начали миграцию части публичной сети на Open vSwitch, что позволило нам запустить межсетевые экраны с сохранением состояния на основе потоков Open vSwitch, а в марте 2021 года...netfilter

Составные части хоста виртуальной машины
Мы уже выяснили, что важные части сетевого стека работают на виртуальных машинах; но что они должны предоставлять для функционирования облачного сервера?

Для большинства серверов требуется доступ к Интернету, чтобы система и её сервисы были доступны как из дома, так и из-за рубежа. Некоторые серверы используют частные сети (Private Networks), либо вместо общедоступных сетей, либо совместно с ними, которые соединяют серверы, балансировщики нагрузки и, возможно, выделенные серверы через частную виртуальную сеть, доступ к которой имеют только ваши системы. Трафик частной сети инкапсулируется с помощью виртуальной расширяемой локальной сети (VXLAN) и уникального виртуального идентификатора сети (VNI) для каждой частной сети. Сетевой стек хоста гарантирует, что только участники, подключенные к соответствующей частной сети, могут отправлять или получать трафик.

Для управления доступом к вашим сервисам, доступным из Интернета, мы предлагаем функцию облачного брандмауэра. Она позволяет контролировать доступ к определенным портам или протоколам сервера, а также ограничивать трафик, который может покидать сервер. Это должно происходить как можно ближе к серверу, то есть на хосте. Создание централизованных брандмауэров с отслеживанием состояния потребовало бы дополнительного оборудования и сетевых наложений для передачи «чистого» трафика на серверы и значительно усложнило бы задачу обеспечения высокой доступности и централизованного отслеживания соединений.

По умолчанию образы наших облачных серверов настроены на использование протокола динамической конфигурации хостов (DHCP) для динамической настройки IPv4-адресов и маршрутов. Следовательно, нам необходимо предоставить DHCP-сервер, чтобы серверы могли запрашивать конфигурацию IPv4-сети для общедоступных и частных сетевых интерфейсов.

В большинстве образов используется для настройки некоторых частей системы, например, для настройки сети IPv6, запуска DHCP для частных сетевых интерфейсов, подключения облачных томов и т.д. Для выполнения этих задач необходимо запрашивать информацию о локальной системе или конфигурационных параметрах пользователя с нашего сервера метаданных, доступного по адресу. Кроме того, сервер метаданных используется многими интеграциями, включая, помимо прочего, наш драйвер CSI, hc-utils, инструменты дистрибутивов, такие как Flatcar Linux и, или Talos Linux.cloud-initcloud-init 169.254.169.254/cloud-initAfterburnIgnition

Для обеспечения максимальной отказоустойчивости и доступности, DHCP-сервер и сервер метаданных работают локально на каждом хосте виртуальной машины.

Помимо этих сервисов, доступных пользователям, на виртуальных машинах работает множество внутренних служб, которые обеспечивают бесперебойную работу серверов, получение сетевой информацией для настройки подключения, а также отслеживание происходящего нашей системой мониторинга.

Однако в этой статье мы сосредоточимся на сетевом стеке и более подробно рассмотрим его внутреннее устройство.

Открыть vSwitch
Большая часть передачи сетевых данных осуществляется с помощью Open vSwitch, или сокращенно OVS, многоуровневого виртуального коммутатора с открытым исходным кодом. Его протокол передачи данных уже давно включен в ядро ​​Linux, а пакеты для пользовательского пространства/управляющей плоскости доступны для всех основных дистрибутивов Linux.

Это сетевой стек по умолчанию для некоторых сред виртуализации, и многие готовые решения поддерживают OVS. К ним относятся, помимо прочих, Proxmox VE, Open Stack и oVirt. Однако мы не используем ни одну из этих сред, а управляем KVM и всеми сопутствующими компонентами с помощью собственных инструментов.

Open vSwitch — это универсальное сетевое решение, предлагающее множество функций, часть из которых мы используем в наших примерах и для настройки. Оно использует OpenFlow, открытый протокол, созданный для настройки плоскости данных сетевых устройств и определения способа пересылки пакетов. Для каждого направления связи должен существовать поток, определяющий, как должны обрабатываться пакеты и куда их необходимо отправлять.

Это могут быть точные совпадения, например, для связи со шлюзом через ARP, NDP, ICMP и т. д., трафика, предназначенного для других участников частной сети, или подключений к сервису в Интернете.

Открытая оркестрация vSwitch — Flusskrebs
Для обеспечения сетевого подключения наших серверов и балансировщиков нагрузки, а также для настройки любых межсетевых экранов, применяемых к серверу, нам необходимо установить необходимые потоки для Open vSwitch, чтобы обеспечить эти соединения и функции.

Распространенным решением для оркестрации Open vSwitch является проект Open Virtual Network (OVN) control plane, который был запущен одновременно с самим OVS и предназначен для обслуживания парка узлов, работающих под управлением Open vSwitch. Он предоставляет уровень абстракции, где можно настраивать логические маршруты и коммутаторы, которые затем преобразуются в OpenFlow.

Когда Open vSwitch был внедрен в стек Hetzner Cloud, мы решили не идти по этому пути и вместо этого разработали собственное решение под названием Flusskrebs (буквально переводится как «речной краб» или «потоковый краб»). Оно написано на Python, предоставляет REST API, используемый локальной частью нашей плоскости управления облаком, и настраивает потоки, необходимые каждой виртуальной машине или балансировщику нагрузки для корректной работы. Это включает в себя потоки для реализации любых правил брандмауэра, настроенных пользователем или нашим бэкэндом, например, для блокировки исходящего SMTP по умолчанию.

Контроллер также выступает в качестве центрального DHCP-сервера для частных сетевых интерфейсов на каждом хосте.

Сетевой стек хоста виртуальной машины
Учитывая общие архитектурные принципы и эти базовые элементы, давайте подробнее рассмотрим сетевой стек нашего хоста виртуальной машины. На следующем рисунке представлен упрощенный обзор внутренней работы сетевого стека хоста виртуальной машины.



Большинство хостов используют два восходящих интерфейса 10 Гбит/с, объединенных в группу агрегации каналов (LAG) или, в Linux, с использованием LACP, подключенных к двум физическим коммутаторам, образующим виртуальное шасси для повышения отказоустойчивости и пропускной способности. Для дальнейшего повышения отказоустойчивости в начале этого года мы начали переход на два маршрутизируемых восходящих канала с использованием BGP, подключенных к двум независимым коммутаторам. Следует отметить, что восходящие интерфейсы не подключены напрямую к мосту OVS, но система Linux осуществляет маршрутизацию между восходящими каналами и OVS. Таким образом, доступность хоста не зависит от OVS, что упрощает установку и обслуживание хоста.bond

Центральный мост Open vSwitch выступает в качестве основного компонента, обеспечивающего сетевое подключение и функции, и все облачные серверы на хосте подключены к нему. Каждый сервер может иметь один публичный сетевой интерфейс, а также до трех частных сетевых интерфейсов. Для отображения потоков, обеспечивающих исходящий трафик с сервера в сеть, используются следующие шаблоны:

# Only process packets with correct source MAC address
table=0, priority=9999, in_port={vm_port_no}, eth_src={mac}, actions=set_field:1->reg0,set_field:{vm_port_no}->reg5,resubmit(,1)
# Only accept packets with an IPv4/IPv6 address associated with the server
table=3, priority=9999, in_port={vm_port_no}, ip_src={ip}, ip, actions=resubmit(,4)
table=3, priority=9999, in_port={vm_port_no}, ipv6_src={ip}/64, ipv6, actions=resubmit(,4)
table=3, priority=9999, in_port={vm_port_no}, arp, arp_op=2, arp_spa={ip}, actions=resubmit(,4)

Входящий трафик к серверу перенаправляется с использованием следующих потоков, по одному для каждого префикса IPv4 или IPv6 соответственно. Сетевой стек хоста идентифицирует себя для виртуальной машины, используя общеизвестный «MAC-адрес виртуального шлюза», который всегда равен .d2:74:7f:6e:37:e3

table=22, priority=9999, in_port={internet_port_no}, ip, ip_dst={ip}, actions=mod_dl_src:d2:74:7f:6e:37:e3,{vm_port_no}
table=22, priority=9999, in_port={internet_port_no}, ipv6, ipv6_dst={ip}/64, actions=mod_dl_src:d2:74:7f:6e:37:e3,{vm_port_no}

Инфраструктурные сервисы, такие как DHCP и серверы метаданных, также подключены к Open vSwitch и работают параллельно с каждым сервером в выделенном пространстве имен Linux для каждого сервера.

Обратите внимание, что DHCP-сервер, показанный на рисунке выше, отвечает только за публичные интерфейсы любого сервера. Как описано выше, контроллер Flusskrebs содержит центральный DHCP-сервер, обрабатывающий все частные сетевые интерфейсы. Процесс подключения к публичному DHCP-серверу также прост:udhcpd

table=1, priority=9999, in_port={vm_port_no}, udp, udp_dst=67, actions={service_port_no}
table=1, priority=9999, in_port={service_port_no}, udp, udp_src=67, actions={vm_port_no}

Наряду с Open vSwitch, для реализации функции межсетевого экрана с сохранением состояния используется отслеживание соединений Linux netfilter. При наличии глобальной общей таблицы отслеживания соединений необходимо предотвратить ее переполнение и обеспечить справедливое использование для всех серверов и клиентов. Это достигается с помощью другого внутреннего проекта, который отслеживает записи отслеживания соединений и устанавливает ограничение в 80 000 активных одновременных соединений на сервер. Если сервер достигает этого лимита, новые соединения не могут быть открыты до тех пор, пока не будет закрыто предыдущее.ctcount

Статус-кво
Эта платформа обработки данных на базе Open vSwitch хорошо нам служила и в основном продолжает служить до сих пор, даже при наличии более миллиона облачных серверов. Однако мы достигли некоторых ограничений и хотели улучшить масштабируемость, отказоустойчивость и гибкость с помощью более специализированного сетевого стека. В течение последних лет наша команда SDN разрабатывала именно такое решение, адаптированное к нашим потребностям, простое в эксплуатации и являющееся прочной основой для новых функций, таких как IPv6 для частных сетей.

В следующей части этой серии мы расскажем о следующих этапах нашего пути, о нашей новейшей полностью самостоятельно разработанной сетевой архитектуре и о том, как она работает. Так что оставайтесь с нами!

Вкратце:

Эксперимент оказался очень успешным. В целом, конструкция нашего API для вывода результатов и аппаратная часть, лежащая в его основе, были надежными и обеспечили очень хорошие результаты. Спрос на вывод результатов оказался намного выше, чем мы ожидали. Для удовлетворения высокого спроса на большие модели нам потребуются дальнейшие улучшения. Пока мы будем вносить эти улучшения, эксперимент продолжится в меньшем масштабе, с меньшими моделями.

Недавно мы запустили наш эксперимент по инференции: API для инференции, который позволяет использовать большие языковые модели (LLM), размещенные на нашей инфраструктуре. Вы можете подключить к нему любой агент, тестовую среду или инструмент для программирования по вашему выбору и использовать наши LLM бесплатно. Таким образом, вы можете протестировать работу LLM на мощном оборудовании, а мы тем временем будем накапливать опыт работы с такими моделями.

Теперь, когда эксперименту по выводу данных исполнилась неделя, мы хотели бы поделиться с вами некоторыми сведениями о том, как он работает, о том, что мы узнали, и о том, каким может быть его будущее. Для этого мы хотели бы показать вам хронологию экспериментальной платформы Hetzner и всех экспериментов, проведенных на ней до настоящего времени.



T — 4 месяца: внедрение платформы Hetzner Experiments Platform с OpenClaw.
С тех пор, как мы начали предлагать нашим клиентам серверы с графическими процессорами, мы тестировали способы обслуживания LLM внутри компании. Благодаря многолетнему опыту работы с Kubernetes, мы смогли создать внутреннюю платформу для вывода результатов, которую использовали для тестирования различных конфигураций серверов и программного обеспечения для обслуживания LLM.

В итоге мы остановились на стеке, состоящем из нескольких серверов GEX131, vLLM и Open WebUI. Эта комбинация позволила нам запустить несколько небольших LLM-моделей, которые мы могли использовать для некоторых внутренних приложений производственного уровня. Это также позволило нам тестировать и оценивать производительность более крупных моделей внутри компании.

В начале 2026 года OpenClaw стал очень обсуждаемой темой в сфере искусственного интеллекта. Многие энтузиасты использовали виртуальные машины Hetzner Cloud для тестирования OpenClaw, но столкнулись с трудностями в безопасной настройке сервера. Чтобы помочь нашим клиентам в решении этой проблемы, мы решили предложить OpenClaw в виде предварительно настроенного экземпляра.

Мы быстро создали новую платформу, которая позволила бы нам предлагать не только OpenClaw, но и другие услуги и продукты, с которыми мы, возможно, захотим поэкспериментировать в будущем. Это позволило бы быстро внедрять изменения и проводить эксперименты, при этом предоставляя меньше гарантий, чем наши более зрелые продукты. Одной из ключевых особенностей стало бы ценообразование: первоначально мы предлагали бы все эксперименты совершенно бесплатно.

OpenClaw также предоставил возможность получить опыт работы с самостоятельным размещением систем вывода. Наш OpenClaw поставлялся с предварительно настроенным собственным API для вывода. API не был общедоступным, а был ограничен OpenClaw, поэтому мы могли в определенной степени контролировать объем запросов. Предлагая вывод только через OpenClaw, мы могли опробовать несколько небольших моделей с открытыми весами в различных конфигурациях. А наши клиенты получали продукт на основе ИИ, полностью разработанный для ЕС.

Чтобы продемонстрировать уникальность платформы Hetzner Experiments Platform, мы создали для нее отдельную панель интерфейса на сайте experiments.hetzner.com

Этот ограниченный эксперимент с OpenClaw дал нам много ценных выводов:

• Небольшие модели, такие как Qwen 3.6, оказались достаточными для большинства сценариев использования OpenClaw.
• GEX131 с одной видеокартой RTX PRO 6000 Blackwell был достаточен для небольших моделей LLM, но не мог эффективно запускать большие модели.
• Многие пользователи высоко оценили тот факт, что это полностью разработано для стран ЕС.
• Качество кода OpenClaw было постоянной проблемой: каждый новый релиз OpenClaw приносил новые трудности, поскольку количество ошибок в исходном коде было довольно велико.

T — 1 месяц: получение специализированного оборудования
В компании Hetzner наши команды разработчиков оборудования постоянно работают над новыми моделями серверов. Одной из таких моделей стал новый сервер, созданный по индивидуальному заказу, в котором вместо одной видеокарты GEX131 размещено восемь графических процессоров RTX PRO™ 6000 Blackwell. Это значительно улучшает возможности сервера для работы с более крупными моделями.

С помощью некоторых из этих серверов с 8 графическими процессорами мы могли бы предлагать нашим клиентам более крупные модели. Эксперимент OpenClaw уже показал, что наши клиенты заинтересованы в темах, связанных с искусственным интеллектом и выводом данных. Однако качество программного обеспечения OpenClaw оставалось проблемой.

Для решения этой проблемы мы решили предложить вывод результатов напрямую в виде API, соответствующего спецификации OpenAI, который мог бы использовать каждый, без необходимости обращаться в OpenClaw. Все, что им понадобится, — это токен авторизации, который они смогут сгенерировать через experiments.hetzner.com на отдельной вкладке «Вывод результатов».

T — 2 недели: сравнительный анализ и выбор подходящих моделей.
Затем последовало множество сравнительных анализов и исследований рынка.

Мы составили список программ магистратуры в области права, которые хотели бы предложить:

• Qwen/Qwen3.6-35B-A3B
• Код Kimi-K2.7
• GLM-5.2
• DeepSeek-V4-Flash-0731

Qwen продолжит эксперимент OpenClaw в качестве меньшей, «базовой» модели. Kimi предложит альтернативу двум крупнейшим моделям, GLM и DeepSeek, ориентированную на программирование. Каждая из этих моделей представляет собой новейшую версию соответствующего семейства LLM.

Единственным исключением был Kimi: K3 уже вышел и обещал отличные результаты в публичных тестах. Однако очень специфические лицензионные требования K3 не позволяли нам предложить его в качестве бесплатного эксперимента.

T — 1 неделя: заключительные приготовления
В рамках заключительной подготовки к эксперименту по формированию выводов некоторые внутренние компоненты были переработаны, чтобы справиться с ожидаемым высоким спросом.

Маршрутизация запросов на вывод значительно улучшилась благодаря внедрению llm-d и внесению изменений в некоторые компоненты маршрутизации, разработанные нами внутри компании. Такие функции, как перенос kv-кэша в оперативную память хоста, также обещали существенное повышение производительности.

Мы также добавили еще несколько специализированных серверов с 8 видеокартами и выделили каждый из них для запуска DeepSeek, GLM или Kimi. А серверы GEX131 с одной видеокартой мы используем для обслуживания более компактной модели Qwen 3.6.

T — 0 часов: запуск
Оценить спрос на эксперимент по анализу выводов было сложно заранее. Чтобы подстраховаться, мы распределили запуск на несколько дней:

7 августа мы запустили новые модели и эксперимент по выводу результатов на платформе Hetzner Experiments. Это дало первым пользователям выходные, чтобы выявить любые проблемы, которые мы могли пропустить. После выходных, 10 августа, мы начали активно информировать наших клиентов об эксперименте. Мы ожидали, что сарафанное радио в конечном итоге также повысит спрос.

T + 6 часов: достигнут лимит вместимости.
Информация распространялась быстро: уже через несколько часов мы заметили резкое увеличение запросов к API для вывода результатов. Спрос превзошел наши самые оптимистичные ожидания и продолжал расти высокими темпами.

Модель Qwen 3.6, которая была моделью по умолчанию для OpenClaw, оказалась самой популярной в первый день, как по количеству запросов, так и по количеству сгенерированных токенов. Другие модели также пользовались высоким спросом, но значительно отставали от Qwen.

Наша система смогла обеспечить достаточную пропускную способность для обработки запросов, но мы уже заметили увеличение задержки:

Для 99-го процентиля времени до получения первого токена (TTFT) наблюдались кратковременные скачки в некоторых моделях, но в целом показатели оставались достаточно хорошими, составляя в большинстве случаев от 5 до 10 секунд.

Ещё одним сюрпризом стало резкое увеличение количества экземпляров OpenClaw. Хотя ожидался некоторый рост спроса, число экземпляров в первый же день резко возросло. Наш небольшой кластер Kubernetes для запуска экземпляров OpenClaw быстро достигал предела своей пропускной способности. Поэтому мы отключили вкладку OpenClaw на experiments.hetzner.com для всех учетных записей, которые ещё не вошли в платформу Hetzner Experiments Platform.

T + 1 день: как справиться с спросом
На второй день эксперимента количество запросов на все модели резко возросло, и это повторилось снова.

Стали проясняться закономерности использования:

• Наибольший интерес вызвал DeepSeek. Многие пользователи сообщили о благоприятных результатах тестирования.
• Квен оставалась популярной, получала очень много небольших запросов.
• Модели GLM и Kimi также пользовались большим спросом, но гораздо меньшим, чем две другие. У модели GLM была самая высокая задержка, и она нуждалась в дополнительной доработке.
• Мы не регистрируем никаких данных о запросах, но наши показатели токенов указывают на то, что многие пользователи в это время все еще запускали тесты производительности.

Однако такое количество запросов превышало возможности нашей экспериментальной инфраструктуры. Время получения первого токена (TTFT) резко возросло, достигнув пика почти в 10 минут для 99-го процентиля, что временами делало API практически непригодным для использования. Наш эксперимент не был рассчитан на такой масштаб запросов, и это сказалось на результатах.

Особенно сложной задачей было большое количество небольших, одновременно обрабатываемых запросов. Чтобы лучше справляться с этим, мы сократили количество принимаемых нами параллельных запросов.

Мы также получили множество отзывов относительно настроек логики различных моделей, которые некоторые пользователи сочли неинтуитивными.


T + 2 дня: дополнительные настройки, больше оборудования
Спрос на обработку данных еще больше возрос, доведя нашу инфраструктуру обработки данных до предела. В то время как количество запросов к конечной точке API снижалось, общее количество входных токенов продолжало расти.



Стремясь увеличить вычислительную мощность, мы смогли собрать еще несколько специализированных серверов с 8 видеокартами и добавили их в пул, обслуживающий GLM, поскольку эта модель в то время испытывала наибольшие трудности.

Теперь закономерности использования стабилизировались и будут наблюдаться до конца недели:

• DeepSeek столкнулся со все более сложными запросами, содержащими огромное количество входных и выходных токенов.
• Квен продолжала получать очень большое количество мелких запросов.
• GLM и Kimi получили запросы среднего размера, но на более низком уровне, чем две предыдущие компании.
• В среднем количество запросов было больше, чем в первый день. Это указывало на более широкое использование сервиса в практических целях, с большими массивами реальных данных.
• Благодаря нашим доработкам, во всех моделях наблюдалось повышение производительности.
• В часы пик большое количество запросов тратило минуты на ожидание в очереди, прежде чем сервер с графическим процессором мог начать обработку запроса на вывод результатов.

В течение недели мы опробовали множество улучшений: общие ограничения скорости обработки запросов были снижены, чтобы дать большему количеству пользователей возможность принять участие в эксперименте. Некоторые модели использования показались нам вредоносными, поэтому мы предприняли шаги по ограничению скорости и фильтрации таких запросов. Фактическое использование также отличалось от результатов наших бенчмарков. Мы выяснили, что для некоторых моделей меньшее количество одновременных запросов на экземпляр является наиболее оптимальным с точки зрения пропускной способности. Благодаря этому изменению общая пропускная способность токенов в эксперименте увеличилась.

Мы также расширили парк оборудования для OpenClaw. Первые пользователи OpenClaw продолжали создавать всё больше экземпляров OpenClaw. Однако количество программных проблем с OpenClaw также увеличилось: многие экземпляры OpenClaw неправильно настраивались по запросу пользователей и в итоге оказывались в нерабочем состоянии.

T + 7 дней: подведение итогов и сокращение масштабов эксперимента.
Оглядываясь назад, спустя неделю, мы многому научились:

• Спрос оказался намного выше, чем мы ожидали, как по количеству пользователей, так и по числу запросов и токенов на запрос. Серверы с 8 графическими процессорами доказали свою способность обрабатывать большие модели, но спрос оказался слишком высок для небольшого количества серверов, участвовавших в нашем эксперименте. Метрики также выявили некоторые узкие места в программном обеспечении, используемом для маршрутизации и обработки запросов.
• Для устранения некоторых из этих узких мест потребуется исключить оборудование из пула, используемого для API вывода данных, чтобы протестировать некоторые изменения. Мы также рассмотрим возможность улучшения нашей документации, добавив больше подробностей и руководств, чтобы упростить ее использование для начинающих.
• Мы также пересмотрим наш выбор LLM на основе рассмотренных нами метрик. Возможно, мы также рассмотрим другие варианты использования, такие как переранжирование или встраивание, как это используется в конвейерах RAG. Кроме того, мы критически оценим эксперимент OpenClaw и усилия, необходимые для его поддержки.
• Эксперимент по выводу данных продолжится, но в уменьшенном масштабе: мы продолжим предоставлять доступ к небольшим моделям, таким как Qwen 3.6 и 3.8, но сделаем перерыв в предоставлении доступа к большим моделям.

Попробуйте сами на experiments.hetzner.com Мы продолжим запускать новые проекты и экспериментировать, чтобы увидеть, что еще возможно. Следите за обновлениями, чтобы узнать, что будет дальше.

В связи с постоянно высоким спросом и ограниченной доступностью необходимых аппаратных компонентов, предоставление и расширение облачных томов в нашем центре в Хиллсборо (HIL) в настоящее время возможно лишь в ограниченном объеме.

Мы внимательно следим за ситуацией и прилагаем все усилия для расширения наших мощностей хранения данных.

Благодарим вас за понимание.

По многочисленным просьбам, облачный сервер CPX12 «Стандартная производительность» с 1 виртуальным процессором, 2 ГБ оперативной памяти и 40 ГБ дискового пространства теперь доступен и в наших европейских локациях (FSN1, HEL1 и NBG1).

Этот сервер начального уровня идеально подходит для выполнения задач с низкими требованиями к ресурсам, таких как небольшие веб-сайты и личные блоги, частные VPN/прокси-сервисы, чат-серверы и боты.

https://hetzner.cloud

В связи с сохраняющимся высоким спросом и ограниченной доступностью необходимых аппаратных компонентов, развертывание облачных серверов в наших центрах обработки данных в настоящее время возможно лишь в ограниченном объеме.

В связи с этим мы вынуждены ограничить создание новых облачных серверов как для новых клиентов, так и для некоторых существующих. Выбор затронутых существующих клиентов осуществляется случайным образом. К сожалению, невозможно индивидуально повлиять на конкретные запросы или установить для них приоритет.

Мы постоянно отслеживаем ситуацию и интенсивно работаем над расширением мощностей.

Благодарим вас за понимание.

Нет, это не сон! Теперь Hetzner VPS можно заказать прямо у нас!
С оплатой в криптовалюте и не только…

Просто представьте, вы решили запустить свой продукт, нужен скоростной интернет — 10 Гбит;

Мощный процессор, который справится с любыми задачами;

Быстрые NVMe-диски, чтобы не приходилось ждать часами;

Да и локация где-нибудь в Германии или Финляндии, а может даже в США.

А чтобы не приходилось долго ждать начала работы над проектом — активация любого сервера за 10 секунд, засекайте!

Это все есть на новых VPS от Hetzner.

Доступны все линейки: Intel Gold, AMD Epyc, Ampere, Выделенный CPU — всего от €4,89

Intel Xeon Gold

• 2 Cores / 4 GB RAM / 40 GB SSD — €4.89
• 4 Cores / 8 GB RAM / 80 GB SSD — €7.69
• 8 Cores / 16 GB RAM / 160 GB SSD — €13.29
• 16 Cores / 32 GB RAM / 320 GB SSD — €24.49

AMD EPYC 7002

• 2 Cores / 2 GB RAM / 40 GB SSD — €9.09
• 3 Cores / 4 GB RAM / 80 GB SSD — €15.39
• 4 Cores / 8 GB RAM / 160 GB SSD — €27.99
• 8 Cores / 16 GB RAM / 240 GB SSD — €39.89
• 16 Cores / 32 GB RAM / 360 GB SSD — €54.59

Закажи сервер прямо сегодня — и начни разворачивать проект без ожидания.

Hetzner реструктурировал своё облако. Это всё то же простое в использовании облако, которое вы знаете, но теперь оно стало ещё более гибким и предлагает больше возможностей по привлекательным ценам.

Благодаря нашим новым типам облачных серверов вы можете начать использовать облако по более низким ценам, чем когда-либо прежде. Начиная всего от 2,99 € В месяц вы можете развернуть CX23 с 2 виртуальными ЦП, 4 ГБ оперативной памяти, 40 ГБ дискового пространства и 20 ТБ включенного трафика, сделав это всего за несколько кликов в нашей интуитивно понятной консоли Hetzner. По мере изменения ваших потребностей вы можете легко масштабировать свои облачные ресурсы, в том числе автоматизировать этот процесс через наш API. Кроме того, вы получите доступ к ряду полезных функций, таких как тома для блочного хранения на базе SSD и балансировщики нагрузки, которые помогут повысить производительность ваших приложений и упростить масштабирование.

Оплата по-прежнему гибкая. Наши облачные тарифы не имеют минимального срока действия. Вы можете платить ежемесячно, если используете их большую часть месяца, или почасово, если они вам нужны всего несколько часов или дней. Вы всегда платите по более дешёвому из этих двух вариантов.

Структура наших новых облачных планов максимально расширяет ваши возможности:

• Общие ресурсы: выбирайте типы серверов «Оптимизированные по стоимости» для рабочих нагрузок с низкими требованиями к ЦП или типы серверов «Обычная производительность» при средних и постоянных рабочих нагрузках на ЦП.
• Выделенные ресурсы: при использовании серверов типа «Общее назначение» вам гарантированы неразделенные ресурсы, что отлично подходит для случаев использования с высокой нагрузкой на процессор.

Гибкие общие виртуальные ЦП идеально подходят для сред разработки, тестовых систем и масштабируемых веб-приложений. Выделенные тарифы лучше подходят для сценариев использования с большими вычислительными мощностями и производственными нагрузками. Какой бы тариф вам ни нужен, у нас есть подходящий облачный тариф.

Все наши облачные тарифные планы соответствуют строгим правилам ЕС по защите данных, таким как GDPR. Это также распространяется на наши офисы в Финляндии, США и Сингапуре.

www.hetzner.com/cloud/

github.com/vitobotta/hetzner-k3s

Это инструмент CLI для супербыстрого и суперлегкого создания и управления кластерами Kubernetes в Hetzner Cloud с использованием легкого дистрибутива Kubernetes k3s от Rancher. В недавнем тесте было создано кластер HA из 200 узлов (3 главных, 197 рабочих узлов) всего за 4 минуты (при использовании только публичной сети, поскольку частные сети ограничены 100 экземплярами на сеть).

ИНФОРМАЦИОННЫЙ БЮЛЛЕТЕНЬ HETZNER
Мы рады сообщить вам о наших новых продуктах и новостях компании.
Наслаждайся чтением!

HETZNER CLOUD ТЕПЕРЬ ТАКЖЕ В СИНГАПУРЕ
Начиная с этого момента, вы можете получить наши облачные услуги в Сингапуре. Воспользуйтесь нашим новым стратегическим расположением в самом сердце Азии и получите выгоду от быстрых подключений к таким важным рынкам, как Китай, Индия и Япония. Хорошо развитая сетевая инфраструктура Сингапура и многочисленные международные подводные кабели делают его исключительно идеальным местом для улучшения скорости передачи данных.

Посмотрите, как скорость задержки снижается, и наслаждайтесь улучшенной связью с Азиатско-Тихоокеанским регионом. Благодаря новому расположению в Сингапуре вы теперь также можете запросить индивидуальную георезервированную облачную настройку между расположениями Hetzner в Европе, Северной Америке и Азии, чтобы сделать ваши системы на базе Hetzner Cloud более надежными и улучшить их производительность.

Hetzner Cloud позволяет вам гибко настраивать собственные облачные серверы. У вас также есть возможность использовать такие функции, как Volumes для дополнительного пространства хранения на основе SSD и Load Balancers, которые вы можете использовать для гибкого масштабирования ваших приложений и которые могут оптимизировать производительность и доступность приложений. Всего за несколько щелчков вы можете настроить облачные серверы в соответствии со своими конкретными потребностями и начать использовать их в течение нескольких секунд.



В новом месте в Сингапуре у вас есть выбор между общими или выделенными облачными серверами vCPU с мощными процессорами AMD и полным набором функций Hetzner Cloud, и все это по привлекательной цене. Например, начните с нашего общего облачного сервера vCPU CPX11 всего за € 7,90 в месяц или € 0,0127 в час. Для неразделенной мощности vCPU выделенный облачный сервер vCPU CCX13 всего за € 21,50 в месяц или € 0,0345 в час — идеальный начальный уровень.

Станьте одним из первых, кто воспользуется нашими отмеченными наградами облачными серверами в Азии, и будьте уверены, что ваши данные стабильны и безопасны, поскольку они размещены на наших собственных серверах Hetzner.
www.hetzner.com/cloud/

ЗАКАЗАТЬ ДО 2 ТБ ОПЕРАТИВНОЙ ПАМЯТИ ДЛЯ СЕРВЕРОВ DELL
Недавно мы предоставили вам возможность добавлять больше оперативной памяти к выделенным серверам DX153 и DX293; в дополнение к уже доступным модулям оперативной памяти объемом 32 ГБ теперь вы можете добавлять модули оперативной памяти объемом 64 ГБ.
Это позволяет вам заказать до 2048 ГБ оперативной памяти (32 x 64 ГБ) для вашего сервера всего за 22,00 евро в месяц за модуль.
www.hetzner.com/dedicated-rootserver/brands

НОВЫЙ ДИСТРИБУТИВ UBUNTU ДЛЯ ВАШИХ СЕРВЕРОВ
Новая версия LTS для Ubuntu 24.04 теперь доступна для установки на ваших выделенных серверах. Ubuntu 24.04 включает улучшенную производительность и стабильность, а также обновленные программные пакеты и функции безопасности.
ubuntu.com/blog/tag/ubuntu-24-04-lts

2-ФАКТОРНАЯ АУТЕНТИФИКАЦИЯ ДЛЯ ВХОДА В ДОМЕН KONSOLEH
Клиенты, использующие интерфейс администрирования konsoleH, теперь могут активировать двухфакторную аутентификацию для входа в домен. Новая функция поддерживает TOTP (одноразовый пароль с ограниченным сроком действия) с использованием Google Authenticator или KeepassXC, а также Yubikey OTP (одноразовый пароль).
Эту функцию можно найти на konsoleH, перейдя в нужный домен, а затем в «Сервисы; Данные для входа; Вход в домен konsoleH, Двухфакторная аутентификация».

РУКОВОДСТВО: УСТАНОВКА MOX НА ОБЛАЧНОМ СЕРВЕРЕ
В этом руководстве вы узнаете, как установить и настроить полнофункциональный почтовый сервер в Hetzner Cloud.
Mox — это простой в использовании инструмент для реализации сервера электронной почты, который вы можете использовать для запуска собственного сервера электронной почты и получения полного контроля над почтовыми сообщениями.
community.hetzner.com/tutorials/install-and-configure-mailserver-mox-on-debian

Информационный бюллетень HETZNER
Мы рады сообщить вам о наших новых продуктах и ​​новостях компании.
Наслаждайся чтением!

ПОЛУЧИТЕ ВАУ-ЭФФЕКТ: НОВЫЕ ОБЛАЧНЫЕ ПЛАНЫ ЗДЕСЬ
Всего за несколько секунд вы сможете развернуть один из наших четырех новых планов общего облака виртуальных ЦП. Они основаны на процессорах Intel, и их высокая производительность впечатляет вас почти так же, как и их привлекательная цена.

Самый маленький план, CX22, включает в себя 2 виртуальных ЦП, 4 ГБ ОЗУ и 40 ГБ дискового пространства, и все это по непревзойденной цене всего 3,79 евро в месяц или 0,0060 евро в час. Далее идет CX32 с 4 виртуальными ЦП, 8 ГБ ОЗУ и 80 ГБ дискового пространства всего за 6,80 евро в месяц (0,0113 евро в час).

Далее следует CX42 с 8 виртуальными ЦП, 16 ГБ ОЗУ и 160 ГБ дискового пространства за 16,40 евро в месяц (0,0273 евро в час).

И последнее, но не менее важное: CX52 с 16 виртуальными ЦП, 32 ГБ ОЗУ и 320 ГБ дискового пространства по потрясающей цене всего 32,40 евро в месяц (0,0540 евро в час). Кроме того, все эти планы включают 20 ТБ трафика и 1 IPv4-адрес.

Поскольку эти планы общего облака распределяют ресурсы ЦП, они идеально подходят для сред разработки и тестирования, блогов, форумов, CMS, небольших баз данных и VPN-серверов. А если ваши требования изменятся в будущем, вы можете просто масштабировать свой сервер вверх или вниз и даже автоматизировать масштабирование с помощью нашего API.

Оплата также является гибкой. Все наши облачные планы не предусматривают минимального срока действия контракта. В зависимости от того, как долго вы используете сервер, вы можете платить почасово или помесячно. Мы всегда взимаем с вас меньшую сумму из этих двух вариантов.

Используя отмеченный наградами, удобный и интуитивно понятный дизайн Hetzner Cloud, вы сможете воплотить свои мечты в реальность, быстро и легко реализуя свои проекты. И вы можете быть спокойны, зная, что новые планы, размещенные в центрах обработки данных Hetzner в Германии и Финляндии, соответствуют Общему регламенту ЕС по защите данных, GDPR.
www.hetzner.com/cloud/

ВЫ ЗНАЛИ? Жесткий диск емкостью 22 ТБ ДОПОЛНИТЕЛЬНО ДЛЯ ВЫДЕЛЕННЫХ СЕРВЕРОВ AX И EX-LINE
Теперь у вас есть возможность добавить жесткий диск SATA Enterprise емкостью 22 ТБ к любому выделенному серверу AX и EX. Вы можете получить все это дополнительное пространство всего за 27,00 евро в месяц или 0,0433 евро в час.


ОБНОВЛЕНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ УПРАВЛЯЕМЫХ СЕРВЕРОВ И СЧЕТЫ ВЕБ-ХОСТИНГА
Ваши файлы, приложения и службы остаются доступными только до тех пор, пока ваш сервер работает стабильно, безопасно и надежно. Чтобы обеспечить бесперебойную работу всех наших управляемых серверов и учетных записей веб-хостинга, мы будем регулярно обновлять их программное обеспечение до новой версии Debian 12 Bookworm.
Затронутые клиенты заранее получат электронное письмо с дополнительной информацией. Все новые заказы будут автоматически поступать с новым выпуском Debian 12 Bookworm.


ПОГОВОРИТЕ С НАМИ НА ВСЕМИРНОМ КОНГРЕССЕ «МЫ РАЗРАБОТЧИКИ»
Всемирный конгресс WeAreDevelopers — одно из главных событий для программистов на планете.
Более 15 000 разработчиков программного обеспечения, DevOps-инженеров, владельцев продуктов и архитекторов программного обеспечения соберутся в Берлине 17-19 июля 2024 года, чтобы узнать больше и обсудить текущие разработки и будущие тенденции в динамичном мире разработки программного обеспечения.
Мы будем там в качестве экспонента и будем рады интересным беседам с вами на нашем стенде (номер 2_47).
www.wearedevelopers.com/world-congress

ОБУЧЕНИЕ: НАСТРОЙКА КЛАСТЕРА KUBERNETES ДЛЯ ОБЛАКА HETZNER С ПОМОЩЬЮ TERRAFORM
В этом руководстве вы узнаете, как настроить собственный масштабируемый кластер Kubernetes с помощью поставщика Terraform для Hetzner Cloud. В руководстве подробно рассматриваются настройка, масштабирование и доступ к кластеру.
Кроме того, здесь объясняется, как рассчитать стоимость кластера и оптимизировать его работу, чтобы можно было эффективно использовать ресурсы.
Поставщик Terraform для Hetzner Cloud находится в репозитории Hetzner Cloud на GitHub и регулярно обновляется.
community.hetzner.com/tutorials/setup-your-own-scalable-kubernetes-cluster
github.com/hetznercloud/terraform-provider-hcloud